Consider an enterprise having multiple systems and potentially multiple geographic locations. Each transaction of the enterprise with an external entity, and many operations within the enterprise on data and/or systems, generates data. The data may indicate changes in inventory, information about sales and customer relations, etc. Data is generally associated with data objects, and frequently, business objects or data objects having a business context. The change to data associated with one or more objects (e.g., business objects or other objects) is referred to herein as an event. Enterprises generally need to keep track of the events, process the generated data (as may be indicated by the event), and make decisions based on the event.
Traditionally, enterprises store events in operational databases (operational data stores) among many subsystems within the enterprise, which may include subsystems that are hosted on separate machines, and may be geographically separated. An example of geographic separation of subsystems may be a system local to production plant in one city, and a system local to a distribution plant that could be in a different region, different state, different country, or different continent. There is generally a problem within enterprises, especially as the enterprise grows and as business expands geographically, where the enterprise has “too much” data and “too many” systems. While it is understood that “too much” and “too many” are relative terms, the general problem is that the amount of resources required to handle the data and the systems is higher than the enterprise is capable of providing or is willing to provide. When there is too much data and too many systems, the enterprise loses operational data visibility across the enterprise, and any process for handling events becomes very time consuming and expensive.
For example, consider a business that has more than 100 different enterprise systems located in various locations throughout the world. The data is gathered and stored in an operational database, e.g., an online transaction processing (OLTP) database. If someone within the business wanted to answer a question based on the operational data, or the data generated as events, creating a new operational report may not be a possibility. In research on the subject, it was found that in certain cases, such an operational report cannot be created in less than 6 months. The business traditionally has to search multiple stacks to extract and transform the data before creating an operational report. The searching, extracting, and transforming would need to be repeated for each of the different systems in place, which would require the use of many people and systems. Thus, such an operational report is not even considered a possibility because of the inability to access and transform the data in a cost-effective manner.
In general, it has been found that businesses do not have tools that are specific to operational data. As mentioned above, the operational data only exists as an interim state of data that is then stored in data warehouses and a centralized database to hold the operational data store. Use of the data has then required a great deal of programming around the database to make the data accessible.
Additionally, passing the data back and forth throughout the enterprise may have deficiencies in being able to make sense of the information. The use of digital libraries or data stores as discussed above does not help users make sense of the data. Without coordination, the data is difficult to find and obtain, which is one problem leading to the costs mentioned above. Historically, information retrieval from digital libraries or similar data stores required having bitmaps for coordination. The bitmaps had a meaning pre-determined for every single bit in the bitmap. When the amount of data becomes as large as what occurs with modern enterprises, the size of the bitmaps is prohibitive to map meaning to data. Additionally, the use of bitmaps has traditionally been used only to address data stored within a data store, and cannot assist in accessing real-time data throughout the enterprise.
Thus, event data within and outside an enterprise has been inaccessible except through a vast amount of enterprise time and cost to analyze and report on the data. The vast amounts of time and cost make the data generally inaccessible to information workers within the enterprise.
Descriptions of certain details and implementations follow, including a description of the figures, which may depict some or all of the embodiments described below, as well as discussing other potential embodiments or implementations of the inventive concepts presented herein. An overview of embodiments of the invention is provided below, followed by a more detailed description with reference to the drawings.